What's the user level API that this is supposed to affect? _NS_getcwd is clearly for internal use only.

it looks like NSURL::fileSystemRepresentation with a relative path would use it to make it absolute, could be other places too but it was that test that was failing due to the long path prefix

Instead of calling directly to _NS_getcwd from the test, it'd be great if this test could call the client-level API that this affects. So if changing _NS_getcwd is required here because it impacts the FSR of an NSURL, could we instead write a test that checks the output of NSURL's FSR to ensure it's the right value? To me that would be a more valuable unit test to make sure the client level behavior is correct regardless of the output of this function (since as we remove more and more C code this function may go away, but our Swift API won't)

So there is a test (test_fileURLWithPath) that was failing due this prefix, specifically;

        path = TestURL.gFileDoesNotExistName
        url = NSURL(fileURLWithPath: path)
        XCTAssertFalse(url.hasDirectoryPath, "did not expect URL with directory path: \(url)")
        let fileSystemRep = url.fileSystemRepresentation
        let actualLength = strlen(fileSystemRep)
        // 1 for path separator
        let expectedLength = UInt(strlen(TestURL.gFileDoesNotExistName)) + TestURL.gRelativeOffsetFromBaseCurrentWorkingDirectory
        XCTAssertEqual(UInt(actualLength), expectedLength, "fileSystemRepresentation was too short")

Would this be testing the client-level API around how this is being used?

Instead of adding to this _NS_getcwd, I wonder if we should just make this call to the implementation in swift-foundation. Is it feasible to call from CF to a Foundation @_cdecl function here? That way it could call to swift-foundation via FileManager and then we'd be using the same "get CWD" implementation everywhere instead of maintaining two copies of it.

The Foundation call that I think you are referring to would be in Sources/FoundationEssentials/FileManager/FileManager+Directories.swift, specifically

var currentDirectoryPath: String? { .... }

Is that right? But since we can't @_cdecl a computed property, this would require some refactoring. Is this the route we want to take?

If it's possible to make the call from CF to Swift here, I think it would just require a small @_cdecl hop to FileManager.default.currentDirectoryPath. We've used this approach in other places such as here:

https://github.com/swiftlang/swift-foundation/blob/7566cd462073afbdf16ac846d9018d4d0c42c147/Sources/FoundationEssentials/FileManager/SearchPaths/FileManager%2BDarwinSearchPaths.swift#L158-L161

In that case, we added a small C-visible entry point that maps to an appropriate Swift API so that CF can call the Swift API instead of re-implementing the logic in C. if it's feasible to do that here, that sounds like a good direction

is this swiftlang/swift-foundation#1545 what you had in mind? I can update this PR to use it once it's in if so. Or do you want this method in this PR local to this package?

Yeah something like that looks good to me if we can call it from CF (I know CF on Darwin upward links Foundation to perform calls like this, not sure if we do that on Linux/Windows too). But I think we can define that cdecl function here in SCL-F since it uses only public API (right) - that way we can just define it and use it here in the same PR

Instead of calling directly to _NS_getcwd from the test, it'd be great if this test could call the client-level API that this affects. So if changing _NS_getcwd is required here because it impacts the FSR of an NSURL, could we instead write a test that checks the output of NSURL's FSR to ensure it's the right value? To me that would be a more valuable unit test to make sure the client level behavior is correct regardless of the output of this function (since as we remove more and more C code this function may go away, but our Swift API won't)